\section{Motivação}
\label{sec:problema}

A motivação para o desenvolvimento deste trabalho surge do facto que o JDBC não inclui mecanismos para tirar partido de um \gls{multithreaded}.

As operações dos objectos dos pacotes \texttt{java.sql} e \texttt{javax.sql} devem ser \emph{thread-safe} \cite{JDBCTUTREF}, isto é, devem operar correctamente numa situação em que existem diversos threads a aceder a um objecto.
No entanto, apenas garantir o invariante de um objecto não é tirar partido de um ambiente multithreaded, e há mesmo situações em que um objecto não deve ser partilhado entre threads. 

Vejamos a situação representada na Listagem \ref{lst:problem-read}, que mostra o fio de execução de dois threads que se encontram a trabalhar em paralelo sobre o mesmo objecto (\texttt{rs} é uma referência para uma instância de um ResultSet).

\lstinputlisting[firstline=1,lastline=4,caption=Dois threads a operar em simultâneo sobre o mesmo result set.,label=lst:problem-read,frame=tb]{code/problem-resultset.java}

Como não há certezas em relação à ordem em que as operações serão executadas, os resultados são imprevisíveis. Por exemplo, a linha 2 do Thread A pode ser executada, e antes que a sua linha 3 seja executada, a linha 2 do Thread B é executada, e a seguir o Thread A lê o valor da linha a seguir à pretendida. Neste exemplo existe também o problema que quando a linha 2 do Thread B foi executada pretendia-se mover para a próxima linha (a linha anterior à chamada \texttt{absolute(4)}), e afinal moveu-se para a linha 5. 

Vejamos só mais um problema, representado na Listagem \ref{lst:problem-update}.

\lstinputlisting[firstline=6,lastline=9,caption=Dois threads a operar em simultâneo sobre o mesmo result set.,label=lst:problem-update,frame=tb]{code/problem-resultset.java}

O Thread A está a tentar actualizar os valores de uma linha. O Thread B quer mover o result set para uma linha que se encontra 5 linhas à frente da linha actual. O código do Thread B pode executar antes que a chamada \texttt{updateRow()} seja realizada, tendo como consequência a perda dos novos valores do Thread A.

Estas são apenas duas situações problemáticas de várias que podem surgir quando se partilha o mesmo objecto de um ResultSet entre threads.
\\

Como se resolvem estes problemas? Bem, uma solução poderia passar por criar um result set para cada thread. Mas isso implica a criação e execução de uma statement para cada thread. É facilmente perceptível que esta situação cria desperdício de recursos.
Outras soluções envolvem a criação de mecanismos especiais ao nível da aplicação, de modo a providenciar um ambiente realmente concorrente, ou então ser o próprio driver fornecer tais mecanismos.
Estas soluções serão discutidas no próximo capítulo.
